Dynamic Calibration of Reservoir Simulation Models using Pattern Recognition

ABSTRACT

Methods for validating reservoir simulation models can include determining one or more time segments of fluid recovery of a reservoir; generating, for a first time segment, one or more streamlines on a full simulation grid corresponding to the reservoir by performing one or more reservoir simulations; generating, for the first time segment, one or more drainage volumes; generating, for the first time segment, grid regions along one or more no-flow boundaries of the one or more drainage volumes; generating, for the first time segment, sector models corresponding to the grid regions; performing, for the first time segment, a history matching process corresponding to a time phase simultaneously on each of the sector models to generate, for each sector model, a history matching output; and comparing, for the first time segment and for each sector model, the history matching output for that sector model to a tolerance threshold.

TECHNICAL FIELD

The present disclosure generally relates to dynamic calibration ofreservoir simulation models, which may sometimes be referred to ashistory matching.

BACKGROUND

Reservoir simulation is an area of reservoir engineering in whichcomputer models are used to predict the flow of fluids (typically, oil,water, and gas) through porous media. The creation of simulation modelsof oil fields and the calculations of field development on their basisis one area of activity of engineers and oil researchers. A reservoirsimulation model can describe the physical processes active in areservoir. One purpose of simulation is estimation of field performance(for example, oil recovery) under one or more producing schemes. Whilethe actual field can be produced only once, at considerable expense, amodel can be produced or run many times at relatively lower expense overa relatively short period of time. Observation of model results thatrepresent different producing conditions can aid in the selection of adesired set of producing conditions for the reservoir.

History matching can generally refer to the act of adjusting a reservoirsimulation model until it closely reproduces (for example, within athreshold accuracy) the past behavior of a reservoir. For example,production and pressures generated by the reservoir simulation model fora given time phase are matched with the historical production andpressures of the actual reservoir during that time phase as closely aspossible. Once a reservoir simulation model is history matched, it canbe used to simulate future reservoir behavior with a higher degree ofconfidence.

SUMMARY

This specification describes systems and methods that provide, whencompared with traditional techniques, enhancements in the accelerationof reservoir simulation modeling by progressive history matching basedon streamline pattern recognition. The systems and methods introducesplitting time and resource intensive history matching processes into aprogressive sequence of dynamic model updates per distinctive phase offluid recovery (for example, primary, secondary, tertiary) or drivemechanism (for example, piston drive, bottom drive). Splitting isperformed in the time and space domain. Each segment of time-spacedomain is dynamically calibrated (that is, history matched)simultaneously (that is, in parallel), which can provide, when comparedwith traditional techniques, considerable savings in computational timeand computational resources without compromising computational rigor.The systems and methods described in this specification can alsointroduce advanced spatial conditioning of no-flow boundaries/volumes byusing pattern recognition based on streamline analysis and by deployingimage analysis with model parameterization and dimensionality reduction.

In at least one aspect of the present disclosure, a system is provided.The system includes a computer-readable medium comprisingcomputer-executable instructions; and at least one processor configuredto execute the computer-executable instructions. When the at least oneprocessor executes the computer-executable instructions, the at leastone processor is configured to perform operations. The operationsinclude determining one or more time segments of fluid recovery of areservoir by analyzing a production history of the reservoir. Theoperations include generating, for a first time segment of the one ormore distinctive time segments, one or more streamlines on a fullsimulation grid corresponding to the reservoir by performing one or morereservoir simulations. The operations include generating, for the firsttime segment, one or more drainage volumes by performing image analysisand compression on the streamlines. The operations include generating,for the first time segment, a plurality of grid regions along one ormore no-flow boundaries of the one or more drainage volumes. Theoperations include generating, for the first time segment, a pluralityof sector models corresponding to the plurality of grid regions bysegmenting the full simulation grid along the one or more no-flowboundaries. The operations include performing, for the first timesegment, a history matching process corresponding to a time phasesimultaneously on each of the plurality of sector models to generate,for each sector model of the plurality of sector models, a historymatching output. The operations include comparing, for the first timesegment and for each sector model of the plurality of sector models, thehistory matching output for that sector model to a tolerance threshold.

The operations can further include determining, for the first timesegment and based on the comparing, whether the history matching outputfor every sector model of the plurality of sector models satisfies thetolerance threshold. The operations can further include reconstructing,for the first time segment and in response to determining that thehistory matching output for every sector model satisfies the tolerancethreshold, the full simulation grid by merging the plurality of sectormodels. The operations can further include determining whether thehistory matching process has been performed for all time segments of theone or more time segments. The operations can further include, inresponse to determining that the history matching process has not beenperformed for all time segments of the one or more time segments,repeating one or more of the operations for a second time segment of theone or more time segments.

The full simulation grid can include a three-dimensional simulationgrid.

Performing image analysis and compression can include performing adiscrete cosine transform technique. Performing image analysis andcompression can include performing a pattern matching process toestablish the one or more no-flow boundaries of the one or more drainagevolumes.

The plurality of sector models can include at least one of: a matrixporosity model, a matrix permeability model, a fracture porosity model,a fracture permeability model, a saturation model, a rock type model, ora fluid region model.

These and other aspects, features, and implementations can be expressedas methods, apparatus, systems, components, program products,non-transitory computer storage mediums, means or steps for performing afunction, and in other ways, and will become apparent from the followingdescriptions, including the claims.

Implementations of the present disclosure can provide one or more of thefollowing advantages. The methods and systems introduce splitting timeand resource intensive history matching into a progressive sequence ofdynamic model updates, as opposed to traditional methods that performsfull field history matching over long a production history. Whencompared with traditional approaches, the systems and methods describedin this specification can reduce computer processing time. Suchreduction in time can range from 47% to 86% relative to the traditionalfull field model simulation approaches, depending on the sector.

As used in this specification, the term drainage region can generallyrefer to the reservoir area drained by a well of the reservoir. As usedin this specification, the term drainage volume can generally refer tothe portion of the volume of a reservoir drained by a well of thereservoir.

As used in this specification, the term no-flow boundary can generallyrefer to a boundary of a reservoir that does not allow flow through it.For example, a no-flow boundary can result in reservoirs with sealingfaults or can be created between producing wells of the reservoir thatare equally spaced and producing at the same rate.

As used in this specification, a streamline trajectory can generallyrefer to a trajectory between a fluid injector and a producing well of areservoir.

The details of one or more embodiments of these systems and methods areset forth in the accompanying drawings and the following description.Other features, objects, and advantages of these systems and methodswill be apparent from the description and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

The patent or application file contains at least one drawing executed incolor. Copies of this patent or patent application publication withcolor drawing(s) will be provided by the Office upon request and paymentof the necessary fee.

FIG. 1 is a schematic of a simulation grid for modeling a reservoirproductions wells (producers) and injection wells (injectors).

FIG. 2 is a schematic rendering of distinctive phases of hydrocarbonfluid recovery.

FIG. 3 is a schematic rendering of different drive mechanisms/wellconfigurations.

FIG. 4 is a flowchart of progressive history matching for calibrating areservoir simulation model.

FIG. 5 is a block diagram illustrating an example system for dynamiccalibration of reservoir simulation models.

FIG. 6 is a flowchart of progressive history matching for calibrating areservoir simulation model using the simulation model to generatedrainage regions to subdivide the model.

FIG. 7 is a schematic illustrating on-the-grid tracking of no-flowboundaries to create grid-conformed boundaries for drainage regionsplitting process.

FIG. 8 is a flowchart of progressive history matching for calibrating areservoir simulation model using streamline pattern recognition togenerate drainage regions to subdivide the model.

FIG. 9 is a flowchart further detailing the streamline patternrecognition used to generate drainage regions to subdivide the model inthe method of FIG. 8.

FIG. 10 illustrates streamline trajectories generated by and extractedfrom full physics, finite-difference simulation of a reservoir.

FIG. 11 illustrates splitting a model of the reservoir shown in FIG. 10into 3 drainage volumes following distinctive no-flow boundaries.

FIG. 12 schematically illustrates the process of sector model processingin reservoir simulation in conjuncture with typical reservoir pressurebehavior through distinctive phases of hydrocarbon recovery.

FIG. 13 is a block diagram of an example computer system used to providecomputational functionalities associated with described algorithms,methods, functions, processes, flows, and procedures described in thepresent disclosure.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

The systems and methods described in this specification can provide forthe acceleration of reservoir model simulations by introducing a splitand merge approach, which can be constrained by generated drainageregions confined by no-flow boundaries. The systems and methods cansplit history matching over long production histories of a reservoir,which can be both time and resource intensive, into a progressivesequence of dynamic model updates per distinctive phase of fluidrecovery. The splitting can be performed in the time (i) and space (j)domain, in which each segment of the time-space domain is dynamicallycalibrated (that is, history matched) simultaneously (that is, inparallel). This approach can be particularly useful for real-timehistory matching of large-scale reservoir simulation models (forexample, on the order of 10⁷ grid cells and 10⁴ wells). This approachcan also be particularly useful for secondary and tertiary phase wellplacement strategies (such as when performing flank injection andpattern injection).

FIG. 1 is a schematic of a simulation grid 10 for modeling a reservoir12 including productions wells (producers) 14 and injection wells(injectors) 16. The reservoir 12 has 5 distinct drainage regions. Aftercalibration, a simulation model based on the simulation grid could beused, for example, to test possible well placements before investing thetime and resources required to drill the wells.

FIG. 2 is a schematic rendering of distinctive phases of hydrocarbonfluid recovery. FIG. 2 illustrates typical pressure behavior of areservoir through distinctive phases of hydrocarbon recovery. Table 1presents the relationship between hydrocarbon recovery phase, liftmechanism, and time segment.

TABLE 1 Hydrocarbon Time recovery phase Mechanism segment PrimaryNatural flow I, II Artificial lift Secondary Water-flooding III Pressuremaintenance Tertiary Thermal (steam, combustion) IV Gas injection (CO2,nitrogen) Chemical treatment Other (microbial, EM, acoustic)

Hydrocarbon recovery can be defined by three phases: a primary phase, asecondary phase, and a tertiary phase. The primary phase refers to astage in which natural reservoir energy, such as gasdrive, waterdrive,or gravity drainage, displaces hydrocarbons from the reservoir, into thewellbore, and up to the surface. In some cases, the primary phaseincludes artificial lift, which describes a system that adds energy tothe fluid column in a wellbore with the objective of initiating andimproving production from the well. The primary phase can correspond toa first time segment I and a second time segment II, as discussed laterin this specification. The secondary phase refers to a stage in which anexternal fluid, such as water or gas, is injected into the reservoirthrough injection wells located in rock that has fluid communicationwith the production wells. The secondary phase can include maintainingreservoir pressure (that is, pressure maintenance) to displacehydrocarbons toward the wellbore (for example, using waterflooding). Thesecondary phase can correspond to a third time segment III, which isdiscussed later in this specification. The tertiary phase refers to astage in which further hydrocarbon recovery methods are performed afterthe secondary phase, such as thermal methods, gas injection, andchemical flooding (for example, using alkali, surfactant, or polymeragents). Other techniques can also be involved, such as microbialtechniques, electromagnetic (EM) techniques, and acoustic techniques.The tertiary phase can correspond with a fourth time segment IV, whichis discussed later in this specification.

In FIG. 2, t^(HC) corresponds to different phases of hydrocarbon (HC)recovery (designated with roman numerals I-IV) while t^(DR) correspondsto the time associated with a given drainage region (DR) remainingapproximately constant (or within the boundaries of pre-selectedtolerance). A reservoir simulation model can determine the distinctivetime segments by analyzing historical pressure behavior data of thegiven reservoir. For example, reservoir pressure typically drops duringtime segments I and II (that is, during the primary phase) and begins torise during time segments III and IV (that is, during the secondary andtertiary phases).

FIG. 3 is a schematic rendering of different drive mechanisms/wellconfigurations. As used in this specification, vertical wells refer towells that use a piston like fluid mechanism for driving hydrocarbonfluid recovery. Horizontal wells and multi-lateral wells refer to wellsthat use bottom-up (vertical drive), as well as lateral drivemechanisms, for driving hydrocarbon fluid recovery. As will be shownlater, changes in the drive mechanism/well configurations can alter adrainage regions shape in time. A model can be configured to assumedrainage regions exists during a time step in which there are minimumevents and consistent fluid drive mechanism. This can allow the drainageregions to be processed during this time step as a stand-alone model.The processed regions can then be combined into a full model and a newset of drainage regions can be re-created based on any time step. Thecan be repeated for every change in these drainage regions until a finaltime step is reached.

FIG. 4 is a flowchart of a method 20 using progressive history matchingfor calibrating a reservoir simulation model. FIG. 5 is a block diagramillustrating an example system 100 for dynamic calibration of reservoirsimulation models. The system 100 includes the modules mentioned in thefollowing description of the method 20.

The method 20 combines 4 distinct steps. In a pre-history matching phase(22), a reservoir simulation module 121 can determine one or more timesegments of fluid recovery of a reservoir by analyzing a productionhistory of the reservoir. For example, historical pressure behavior dataof the reservoir can be analyzed to determine distinctive time segmentsrelated to production phases of the reservoir. In a model-splittingphase (24), the grid and sector module 123 splits the full model grid(for example, the grid shown in FIG. 1) into sectors corresponding todrainage regions. In a history matching phase (26), simulation modelsbased on the sectors corresponding to individual drainage regionscalibrates the models by history matching. In a sector merge phase (28),the grid and sector module 123 merges the calibrated models for eachsector back into the full model grid.

Referring to FIG. 5, the system 100 includes hardware and softwarecomponents, such as one or more processors 110 and a memory 120, whichare interconnected by a data bus 106. The memory 120 can be anynon-transitory computer-readable storage medium and is capable ofstoring computer-readable instructions executable by the processors 110.In the illustrated embodiment, the memory 120 stores executableinstructions associated with a reservoir simulation module 121, animage-processing module 122, a grid and sector module 123, and ahistory-matching module 124, to enable the system 100 or othercomponents and devices to carry out the techniques described in thisspecification. As used in this specification, the term “module” isdefined broadly to include, for example, any code, program, firmware,software object, or other software device or arrangement that can beexecuted by one or more processors to perform one or more activities,functions, or facilities.

The reservoir simulation module 121 can analyze the production historyof a given reservoir and, based on the analysis, determine distinctivetime segments of hydrocarbon fluid recovery for that reservoir. In theillustrated implementation, the reservoir simulation module 121 isconfigured based on the assumption that the reservoir simulation moduleunder consideration automatically generates drainage regions and thatthe boundaries of generated drainage regions remain approximatelyconstant during each individual distinct phase of hydrocarbon recovery.

FIG. 6 is a flowchart of a specific implementation 200 of the method ofthe progressive history matching method 20. This implementation uses thesimulation module 121 to generate drainage regions to subdivide themodel.

In a pre-history matching phase (22), the reservoir simulation module121 determines one or more time segments of fluid recovery of areservoir by analyzing a production history of the reservoir (201). Forexample, historical pressure behavior data of the reservoir can beanalyzed to determine distinctive time segments related to productionphases of the reservoir. These time segments correspond to phases of HCfluid recovery, drive mechanisms or well configurations discussed withreferences to FIGS. 2 and 3. This implementation uses a reservoirsimulator that automatically generates drainage regions as thesimulation module 121 and is based on the assumption that the boundariesof the generated drainage regions remain approximately constant (orwithin the boundaries of pre-selected tolerance) during individualdistinct phases of hydrocarbon recovery, drive mechanism or wellconfiguration, t_(i). This assumption is more appropriate when wellfieldconfigurations and fluid allocation offset intake or injection remainconsistent. When new wells are drilled or fluid allocations change inthe calibration data set, t_(i) is incremented and a new set of drainageregions is generated

In a model-splitting phase (24), the grid and sector module 123 splitsthe full model grid (for example, the grid shown in FIG. 1) into sectorscorresponding to drainage regions. In this implementation, a reservoirsimulation is run that generates drainage regions on full-sizesimulation grid (202). The simulation time corresponds to the distinctphase of hydrocarbon, t_(i) where t_(i)⊂(0, T), i=index of distinctivephase of fluid recovery; and T is the full production history of thereservoir

As previously discussed, this implementation uses a reservoir simulatorthat automatically generates drainage regions as the simulation module121. The boundaries of generated drainage regions are automaticallytracked and assigned the no-flow boundary conditions as per ΔQ_(f)≈0 andΔp≈0, which represent approximate zero fluid flow difference andapproximate zero pressure difference on the boundary surface,respectively (203). For example, these boundary lines separate thedrainage regions shown in FIG. 1 The tolerances for assigning theΔQ_(f)≈0 and Δp≈0 condition are specified as:

ΔQ _(f) ^(j)(t _(i))−ΔQ _(f) ^(j)(t _(i-1))<<ε_(Q)  (1)

Δp ^(j)(t _(i))−Δp ^(j)(t _(i-1))<<ε_(p)  (2)

where indices j and I run over distinctive phases of fluid recovery andnumber of distinctive drainage regions, respectively. The residual errorc is determined based on computational convergence error of the solverbuilt in reservoir simulator. These boundaries between flow regions areconformed to the grid to create j sub-grid regions with assignedcorresponding reservoir simulation model properties (for example, matrixporosity, matrix permeability, fracture porosity, fracture permeability,saturation, rock types, and fluid regions) (204).

FIG. 7 is a schematic illustrating this process of tracking of no-flowboundaries to create grid-conformed boundaries for drainage regionsplitting process. As shown, the boundaries of drainage regions definedby streamlines are tracked (A), and grid-conformed boundaries ofdrainage regions defined by streamlines are created (B). In theillustrated implementation, the grid-conformed boundaries are created byaggregating the assigned no-flow boundary conditions ΔQ_(f)≈0 and Δp≈0,which reflect approximate zero fluid flow difference and approximatezero pressure difference on all the boundary surfaces, respectively.Pattern recognition techniques (such as, streamline-based registration,clustering, or both) are used to track and generate separation linesalong the outer boundaries of any region divided by the ΔQ_(f)≈0 andΔp≈0 conditions. A snap-to-grid approach is used to conform theseparation lines to the underlying reservoir simulation grid.

Referring back to FIG. 6, after the grid-conformed boundaries arecreated, the simulation grid is automatically split into j sub-gridscorresponding to j simulation models sectors confined by no-flowboundaries (205)

In a history matching phase (26), simulation models based on the sectorscorresponding to individual drainage regions calibrate the models byhistory matching. Referring back to FIG. 4, the history-matching module124 performs history matching for each of the j sector modelssimultaneously for each time segment, usually beginning with the firsttime segment I (206). In the illustrated implementation, historymatching is performed using computer-assisted history matching (AHM). Insome implementations, history matching is performed using a traditionalmanual approach. In some implementations, simultaneous simulation jobsubmission is performed by using parallel high performance computing. Inthis implementation, the process 100 sequentially monitors and checks ifthe history matching performed on the sector models is completed for allsectors within specified accuracy and precision tolerances (207-208). Ifnot, the history matching (206) is repeated until conditions are met.

In the sector merge phase (28), the grid and sector module 123 mergesthe calibrated models for each sector back into the full model grid.Once the specified accuracy and precision tolerances are achieved, the jsub-grids, corresponding to j simulation sector models are automaticallymerged back into a full-size simulation grid, which includes allreservoir simulation model properties previously split into the sectormodels (209).

This process is repeated for each time phase until the time phase t_(i)of the production history has reached full production history T(210-211).

FIG. 8 is a flowchart showing another implementation 700 of the method20 for dynamic calibration of a reservoir simulation model. Thisimplementation is substantially similar to the implementation 200 butuses streamline pattern recognition to generate drainage regions tosubdivide the model.

The method 700 includes determining one or more time segments of fluidrecovery of a reservoir by analyzing a production history of thereservoir (block 701). For example, historical pressure behavior data ofthe reservoir can be analyzed to determine distinctive time segmentsrelated to production phases of the reservoir.

The method 700 includes generating, for a first time segment of the oneor more time segments, one or more streamline trajectories on a fullsimulation grid corresponding to the reservoir (block 702). To generatethe one or more streamline trajectories, one or more reservoirsimulations can be performed, as described previously with reference toFIG. 1 and FIG. 3. In some implementations, the full simulation gridincludes a three-dimensional simulation grid.

The method 700 includes generating, for the first time segment, one ormore drainage volumes (block 703). The one or more drainage volumes canbe generated by performing image analysis and compression on thegenerated one or more streamline trajectories. In some implementations,performing image analysis and compression includes performing a discretecosine transform technique. In some implementations, performing imageanalysis and compression includes performing a pattern matching process.

The method 700 includes generating, for the first time segment, aplurality of grid regions along one or more no-flow boundaries of theone or more drainage volumes (block 704). The method 700 includesgenerating, for the first time segment, a plurality of sector modelscorresponding to the plurality of grid regions (block 705).

The method 700 includes generating, for the first time segment and foreach sector model of the plurality of sector models, a history matchingoutput (block 706). For example, the history matching can estimate afield performance amount (such as an oil recovery amount) of thereservoir during the first time segment. The method 700 includescomparing, for the first time segment and for each sector model, thehistory matching output to a tolerance threshold (block 707). Thetolerance threshold can be based on accuracy and precision tolerances.

The method 700 includes determining, for the first time segment andbased on the comparing, whether the history matching output for everysector model of the plurality of sector models satisfies the tolerancethreshold (block 708). For example, the history matching output can becompared with observed real-world output, and based on that comparison,the accuracy, precision, or both, of the history matching process can bedetermined.

The method 700 includes reconstructing, for the first time segment andin response to determining that the history matching output for everysector model satisfies the tolerance threshold, the full simulation gridby merging the plurality of sector models (block 709).

The method 700 includes, determining whether the history matchingprocess has been performed for all time segments (block 710), and, inresponse to determining that the history matching process has not beenperformed for all time segments, repeating block 702-710 for a secondtime segment (block 711).

FIG. 9 is a flowchart further detailing the streamline patternrecognition used to generate drainage regions to subdivide the model inthe method of FIG. 8. The flowchart shows a method 800 for performingimage analysis and compression. The method 800 includes exporting, for afirst time segment of a plurality of time segments of fluid recovery ofa reservoir, a grid property of one or more grid cells of a simulationgrid (block 801).

The method 800 includes parameterizing one or more vertical layers ofthe exported grid property to generate one or more parametercoefficients and one or more basis functions for each the one or morevertical layers (block 802). In some implementations, parameterizingincludes performing DCT parameterization.

The method 800 includes classifying each parameter coefficient of theone or more parameter coefficients by performing a pattern recognitiontechnique on each of the one or more parameter coefficients (block 803).In some implementations, the pattern recognition technique includesperforming k-means clustering. In some implementations, the patternrecognition technique includes performing one or more machine learningtechniques.

The method 800 includes performing inverse parameterization on each ofthe classified parameter coefficients (block 804). In someimplementations, performing inverse parameterization includes performingtwo-dimensional DCT parameterization.

The method 800 includes assigning property boundaries of the inverseparameterized classified parameter coefficients as no-flow boundaries ofdrainage volumes of the reservoir (block 805).

FIG. 10 illustrates streamline trajectories generated by and extractedfrom full physics, finite-difference simulation of a reservoir. Asshown, the streamline trajectories show flow connectivity betweenindividual injectors (such as fluid injectors) and correspondinghydrocarbon (HC) producers. Referring back to FIG. 5, the reservoirsimulation module 121 is capable of performing a reservoir simulationfor the given reservoir to generate streamline trajectories on athree-dimensional simulation grid for the given reservoir for aparticular time segment (t_(i)), typically beginning with time segmentI. In the illustrated implementation, the simulation time used for thegiven reservoir corresponds to each distinct phase of hydrocarbonrecovery. In the illustrated implementation, the reservoir simulationmodule 121 is capable of performing full physics, finite-differencesimulation to generate the streamline trajectories.

Referring back to FIG. 1, the image-processing module 122 is capable ofperforming image analysis and image compression on the generated one ormore streamline trajectories to generate three-dimensionalstreamline-conditioned drainage volumes for each distinct time segmentof hydrocarbon recovery, typically beginning with time segment I. Insome implementations, the image-processing module 122 is capable ofperforming image analysis and compression using a discrete cosinetransform (DCT) to generate drainage volumes for each distinct phase ofhydrocarbon recovery.

In the illustrated implementation, performing image analysis includesone or more of the following steps. For a current time segment, theimage-processing module 122 automatically extracts grid cell blocks,which are traversed by streamline trajectories, and converts them into athree-dimensional grid property for the current time segment. Theimage-processing module 122 performs two-dimensional DCTparameterization on a vertical layer k of the extracted grid property.The image-processing module 122 stores DCT coefficients and basisfunctions corresponding to the vertical layer k of the parameterizedgrid property in an intermediate array. The image-processing module 122monitors the progress of DCT parameterization as a function of girdvertical layers. The extraction and parameterization is performed untilall grid vertical layers are parameterized using the two-dimensional DCTparameterization. The image-processing module 122 performs multi-labelclassification pattern recognition on the stored DCT coefficients. Inthe illustrated implementation, performing pattern recognition includesperforming k-means clustering. In some implementations, performingpattern recognition includes using one or more machine learningtechniques (for example, naive Bayesian techniques and neural networks).In some implementations, performing pattern recognition includes usingsupport vector machine techniques. The image-processing module 122stores the classified DCT coefficients and basis functions for alllayers of the streamline grid-cell three-dimensional property. Theimage-processing module 122 performs inverse two-dimensional DCTparameterization on the stored classified DCT coefficients for alllayers of the streamline grid-cell three-dimensional property. Theimage-processing module 122 assigns the property boundaries resultingfrom DCT inversion as no-flow boundaries of drainage volumes, as perΔQf≈0 and Δv≈0, which represent approximate zero fluid flow differenceand approximate zero pressure difference on the boundary surface,respectively.

Following the distinctive no-flow boundaries, the grid and sector module123 is capable of generating a plurality of j sub-grid regions andassigning each j grid region a corresponding reservoir simulation modelproperty (for example, matrix porosity, matrix permeability, fractureporosity, fracture permeability, saturation, rock type, and fluidregions).

FIG. 11 illustrates splitting a model of the reservoir shown in FIG. 10into 3 drainage volumes following distinctive no-flow boundaries. Thegrid and sector module 123 splits the simulation grid into j sub-gridscorresponding to j simulation model sectors confined by no-flowboundaries. The no-flow boundaries of extracted drainage regions arediscretized on the existing grid. The j sub-grid regions areautomatically created with assigned corresponding reservoir simulationmodel properties (such as matrix porosity, matrix permeability, fractureporosity, fracture permeability, saturation, rock type, fluid regions).

FIG. 12 schematically illustrates the process of sector model processingin reservoir simulation in conjuncture with typical reservoir pressurebehavior through distinctive phases of hydrocarbon recovery. As shown,the entire history of hydrocarbon recovery for this reservoir can berepresented in 10 distinctive time steps. Time steps 1 and 2 jointlyrepresent time segments I and II, and the spatial streamlinedistribution remain unchanged within the tolerances of no-flowboundaries as defined previously with respect to equations (1) and (2).Times steps 3 and 4 jointly represent time segment III and the spatialstreamline distribution remain unchanged within the tolerances ofno-flow boundaries as defined by equations (1) and (2). Time steps 5through 10 jointly represent time segment IV, and the spatial streamlinedistribution remain unchanged within the tolerances of no-flowboundaries as defined by equations (1) and (2).

Referring back to FIG. 1, the history-matching module 124 is capable ofsequentially monitoring and verifying that the history matching processperformed on the j sector models is completed for all j sectors withindesired accuracy and precision tolerances for each given time segment,usually beginning with time segment I. If the accuracy and precisiontolerances for all j sectors is not satisfied, another iteration ofhistory matching is performed for a given time segment.

Once the desired accuracy and precision tolerances are satisfied, thehistory-matching module 124 merges the j sub-grids, which correspond toj simulation sector models, into a full-size simulation grid, whichcorresponds to all reservoir simulation model properties. Thehistory-matching module 124 then monitors and verifies that all timesegments have been history matched. If not, then the time segment isincreased by one and the reservoir simulation module performs asimulation to generate streamline trajectories for the next timesegment.

Although specific modules, including the reservoir simulation module121, the image-processing module 122, the grid and sector module 123,and the history-matching module 124 are described as carrying outcertain aspects of the techniques described in this specification, someor all of the techniques may be carried out by additional, fewer, oralternative modules in some implementations.

Table 2 is a chart depicting the results of using the techniquesdescribed in this specification compared with traditional full-fieldapproaches. Several normalization factors were defined to compareoverall simulation times associated with full field approaches andsector model approaches. The normalization factors were defined asfollows: (1) Norm_CPU=Normalization for Total number of cells perCPU=Runtime*(Total Cells/CPU number) and (2) Norm_Wells=Normalizationusing Active Wells fact=Norm_CPU*(No_of_Wells/Max_number_of_Wells. Theresults shown in Table 2 indicate that the techniques described in thisspecification enable reduction in computational time ranging between 47%and 86%, when compared with the full field model simulation.

TABLE 2 CPU Total Active Runtime Model No. Cells Norm_CPU Norm_CPU_%Cells Norm_Wells (h) FULL 6000 1.30E+09 3.25E+06 100.0 4.79E+08 100.015.0 FIELD Sector 1 4000 5.02E+08 1.00E+06 30.9 2.45E+07 14.7 8.0 Sector2 3,000 3.31E+08 2.32E+05 7.1 2.23E+07 1.2 2.1 Sector 3 1,000 3.18E+081.21E+06 37.1 1.57E+07 9.7 3.8 Sector 4 1,000 4.20E+08 1.80E+06 55.55.47E+06 5.0 4.3

FIG. 13 is a block diagram of an example computer system 500 used toprovide computational functionalities associated with describedalgorithms, methods, functions, processes, flows, and proceduresdescribed in the present disclosure (such as the method 300 describedpreviously with reference to FIG. 3), according to some implementationsof the present disclosure. The illustrated computer 502 is intended toencompass any computing device such as a server, a desktop computer, alaptop/notebook computer, a wireless data port, a smart phone, apersonal data assistant (PDA), a tablet computing device, or one or moreprocessors within these devices, including physical instances, virtualinstances, or both. The computer 502 can include input devices such askeypads, keyboards, and touch screens that can accept user information.Also, the computer 502 can include output devices that can conveyinformation associated with the operation of the computer 502. Theinformation can include digital data, visual data, audio information, ora combination of information. The information can be presented in agraphical user interface (UI) (or GUI).

The computer 502 can serve in a role as a client, a network component, aserver, a database, a persistency, or components of a computer systemfor performing the subject matter described in the present disclosure.The illustrated computer 502 is communicably coupled with a network 530.In some implementations, one or more components of the computer 502 canbe configured to operate within different environments, includingcloud-computing-based environments, local environments, globalenvironments, and combinations of environments.

At a high level, the computer 502 is an electronic computing deviceoperable to receive, transmit, process, store, and manage data andinformation associated with the described subject matter. According tosome implementations, the computer 502 can also include, or becommunicably coupled with, an application server, an email server, a webserver, a caching server, a streaming data server, or a combination ofservers.

The computer 502 can receive requests over network 530 from a clientapplication (for example, executing on another computer 502). Thecomputer 502 can respond to the received requests by processing thereceived requests using software applications. Requests can also be sentto the computer 502 from internal users (for example, from a commandconsole), external (or third) parties, automated applications, entities,individuals, systems, and computers.

Each of the components of the computer 502 can communicate using asystem bus 503. In some implementations, any or all of the components ofthe computer 502, including hardware or software components, caninterface with each other or the interface 504 (or a combination ofboth), over the system bus 503. Interfaces can use an applicationprogramming interface (API) 512, a service layer 513, or a combinationof the API 512 and service layer 513. The API 512 can includespecifications for routines, data structures, and object classes. TheAPI 512 can be either computer-language independent or dependent. TheAPI 512 can refer to a complete interface, a single function, or a setof APIs.

The service layer 513 can provide software services to the computer 502and other components (whether illustrated or not) that are communicablycoupled to the computer 502. The functionality of the computer 502 canbe accessible for all service consumers using this service layer.Software services, such as those provided by the service layer 513, canprovide reusable, defined functionalities through a defined interface.For example, the interface can be software written in JAVA, C++, or alanguage providing data in extensible markup language (XML) format.While illustrated as an integrated component of the computer 502, inalternative implementations, the API 512 or the service layer 513 can bestand-alone components in relation to other components of the computer502 and other components communicably coupled to the computer 502.Moreover, any or all parts of the API 512 or the service layer 513 canbe implemented as child or sub-modules of another software module,enterprise application, or hardware module without departing from thescope of the present disclosure.

The computer 502 includes an interface 504. Although illustrated as asingle interface 504 in FIG. 9, two or more interfaces 504 can be usedaccording to particular needs, desires, or particular implementations ofthe computer 502 and the described functionality. The interface 504 canbe used by the computer 502 for communicating with other systems thatare connected to the network 530 (whether illustrated or not) in adistributed environment. Generally, the interface 504 can include, or beimplemented using, logic encoded in software or hardware (or acombination of software and hardware) operable to communicate with thenetwork 530. More specifically, the interface 504 can include softwaresupporting one or more communication protocols associated withcommunications. As such, the network 530 or the interface's hardware canbe operable to communicate physical signals within and outside of theillustrated computer 502.

The computer 502 includes a processor 505. Although illustrated as asingle processor 505 in FIG. 9, two or more processors 505 can be usedaccording to particular needs, desires, or particular implementations ofthe computer 502 and the described functionality. Generally, theprocessor 505 can execute instructions and can manipulate data toperform the operations of the computer 502, including operations usingalgorithms, methods, functions, processes, flows, and procedures asdescribed in the present disclosure.

The computer 502 also includes a database 506 that can hold data for thecomputer 502 and other components connected to the network 530 (whetherillustrated or not). For example, database 506 can be an in-memory,conventional, or a database storing data consistent with the presentdisclosure. In some implementations, database 506 can be a combinationof two or more different database types (for example, hybrid in-memoryand conventional databases) according to particular needs, desires, orparticular implementations of the computer 502 and the describedfunctionality. Although illustrated as a single database 506 in FIG. 9,two or more databases (of the same, different, or combination of types)can be used according to particular needs, desires, or particularimplementations of the computer 502 and the described functionality.While database 506 is illustrated as an internal component of thecomputer 502, in alternative implementations, database 506 can beexternal to the computer 502.

The computer 502 also includes a memory 507 that can hold data for thecomputer 502 or a combination of components connected to the network 530(whether illustrated or not). Memory 507 can store any data consistentwith the present disclosure. In some implementations, memory 507 can bea combination of two or more different types of memory (for example, acombination of semiconductor and magnetic storage) according toparticular needs, desires, or particular implementations of the computer502 and the described functionality. Although illustrated as a singlememory 507 in FIG. 9, two or more memories 507 (of the same, different,or combination of types) can be used according to particular needs,desires, or particular implementations of the computer 502 and thedescribed functionality. While memory 507 is illustrated as an internalcomponent of the computer 502, in alternative implementations, memory507 can be external to the computer 502.

The application 508 can be an algorithmic software engine providingfunctionality according to particular needs, desires, or particularimplementations of the computer 502 and the described functionality. Forexample, application 508 can serve as one or more components, modules,or applications. Further, although illustrated as a single application508, the application 508 can be implemented as multiple applications 508on the computer 502. In addition, although illustrated as internal tothe computer 502, in alternative implementations, the application 508can be external to the computer 502.

The computer 502 can also include a power supply 514. The power supply514 can include a rechargeable or non-rechargeable battery that can beconfigured to be either user- or non-user-replaceable. In someimplementations, the power supply 514 can include power-conversion andmanagement circuits, including recharging, standby, and power managementfunctionalities. In some implementations, the power-supply 514 caninclude a power plug to allow the computer 502 to be plugged into a wallsocket or a power source to, for example, power the computer 502 orrecharge a rechargeable battery.

There can be any number of computers 502 associated with, or externalto, a computer system containing computer 502, with each computer 502communicating over network 530. Further, the terms “client,” “user,” andother appropriate terminology can be used interchangeably, asappropriate, without departing from the scope of the present disclosure.Moreover, the present disclosure contemplates that many users can useone computer 502 and one user can use multiple computers 502.

Implementations of the subject matter and the functional operationsdescribed in this specification can be implemented in digital electroniccircuitry, in tangibly embodied computer software or firmware, incomputer hardware, including the structures disclosed in thisspecification and their structural equivalents, or in combinations ofone or more of them. Software implementations of the described subjectmatter can be implemented as one or more computer programs. Eachcomputer program can include one or more modules of computer programinstructions encoded on a tangible, non-transitory, computer-readablecomputer-storage medium for execution by, or to control the operationof, data processing apparatus. Alternatively, or additionally, theprogram instructions can be encoded in/on an artificially generatedpropagated signal. The example, the signal can be a machine-generatedelectrical, optical, or electromagnetic signal that is generated toencode information for transmission to suitable receiver apparatus forexecution by a data processing apparatus. The computer-storage mediumcan be a machine-readable storage device, a machine-readable storagesubstrate, a random or serial access memory device, or a combination ofcomputer-storage mediums.

The terms “data processing apparatus,” “computer,” and “electroniccomputer device” (or equivalent as understood by one of ordinary skillin the art) refer to data processing hardware. For example, a dataprocessing apparatus can encompass all kinds of apparatus, devices, andmachines for processing data, including by way of example, aprogrammable processor, a computer, or multiple processors or computers.The apparatus can also include special purpose logic circuitryincluding, for example, a central processing unit (CPU), a fieldprogrammable gate array (FPGA), or an application specific integratedcircuit (ASIC). In some implementations, the data processing apparatusor special purpose logic circuitry (or a combination of the dataprocessing apparatus or special purpose logic circuitry) can behardware- or software-based (or a combination of both hardware- andsoftware-based). The apparatus can optionally include code that createsan execution environment for computer programs, for example, code thatconstitutes processor firmware, a protocol stack, a database managementsystem, an operating system, or a combination of execution environments.The present disclosure contemplates the use of data processingapparatuses with or without conventional operating systems, for example,LINUX, UNIX, WINDOWS, MAC OS, ANDROID, or IOS.

A computer program, which can also be referred to or described as aprogram, software, a software application, a module, a software module,a script, or code, can be written in any form of programming language.Programming languages can include, for example, compiled languages,interpreted languages, declarative languages, or procedural languages.Programs can be deployed in any form, including as stand-alone programs,modules, components, subroutines, or units for use in a computingenvironment. A computer program can, but need not, correspond to a filein a file system. A program can be stored in a portion of a file thatholds other programs or data, for example, one or more scripts stored ina markup language document, in a single file dedicated to the program inquestion, or in multiple coordinated files storing one or more modules,sub programs, or portions of code. A computer program can be deployedfor execution on one computer or on multiple computers that are located,for example, at one site or distributed across multiple sites that areinterconnected by a communication network. While portions of theprograms illustrated in the various figures may be shown as individualmodules that implement the various features and functionality throughvarious objects, methods, or processes, the programs can instead includea number of sub-modules, third-party services, components, andlibraries. Conversely, the features and functionality of variouscomponents can be combined into single components as appropriate.Thresholds used to make computational determinations can be statically,dynamically, or both statically and dynamically determined.

The methods, processes, or logic flows described in this specificationcan be performed by one or more programmable computers executing one ormore computer programs to perform functions by operating on input dataand generating output. The methods, processes, or logic flows can alsobe performed by, and apparatus can also be implemented as, specialpurpose logic circuitry, for example, a CPU, an FPGA, or an ASIC.

Computers suitable for the execution of a computer program can be basedon one or more of general and special purpose microprocessors and otherkinds of CPUs. The elements of a computer are a CPU for performing orexecuting instructions and one or more memory devices for storinginstructions and data. Generally, a CPU can receive instructions anddata from (and write data to) a memory. A computer can also include, orbe operatively coupled to, one or more mass storage devices for storingdata. In some implementations, a computer can receive data from, andtransfer data to, the mass storage devices including, for example,magnetic, magneto optical disks, or optical disks. Moreover, a computercan be embedded in another device, for example, a mobile telephone, apersonal digital assistant (PDA), a mobile audio or video player, a gameconsole, a global positioning system (GPS) receiver, or a portablestorage device such as a universal serial bus (USB) flash drive.

Computer readable media (transitory or non-transitory, as appropriate)suitable for storing computer program instructions and data can includeall forms of permanent/non-permanent and volatile/non-volatile memory,media, and memory devices. Computer readable media can include, forexample, semiconductor memory devices such as random access memory(RAM), read only memory (ROM), phase change memory (PRAM), static randomaccess memory (SRAM), dynamic random access memory (DRAM), erasableprogrammable read-only memory (EPROM), electrically erasableprogrammable read-only memory (EEPROM), and flash memory devices.Computer readable media can also include, for example, magnetic devicessuch as tape, cartridges, cassettes, and internal/removable disks.Computer readable media can also include magneto optical disks andoptical memory devices and technologies including, for example, digitalvideo disc (DVD), CD ROM, DVD+/−R, DVD-RAM, DVD-ROM, HD-DVD, and BLURAY.

The memory can store various objects or data, including caches, classes,frameworks, applications, modules, backup data, jobs, web pages, webpage templates, data structures, database tables, repositories, anddynamic information. Types of objects and data stored in memory caninclude parameters, variables, algorithms, instructions, rules,constraints, and references. Additionally, the memory can include logs,policies, security or access data, and reporting files. The processorand the memory can be supplemented by, or incorporated in, specialpurpose logic circuitry.

Implementations of the subject matter described in the presentdisclosure can be implemented on a computer having a display device forproviding interaction with a user, including displaying information to(and receiving input from) the user. Types of display devices caninclude, for example, a cathode ray tube (CRT), a liquid crystal display(LCD), a light-emitting diode (LED), and a plasma monitor. Displaydevices can include a keyboard and pointing devices including, forexample, a mouse, a trackball, or a trackpad. User input can also beprovided to the computer through the use of a touchscreen, such as atablet computer surface with pressure sensitivity or a multi-touchscreen using capacitive or electric sensing. Other kinds of devices canbe used to provide for interaction with a user, including to receiveuser feedback including, for example, sensory feedback including visualfeedback, auditory feedback, or tactile feedback. Input from the usercan be received in the form of acoustic, speech, or tactile input. Inaddition, a computer can interact with a user by sending documents to,and receiving documents from, a device that is used by the user. Forexample, the computer can send web pages to a web browser on a user'sclient device in response to requests received from the web browser.

The term “graphical user interface,” or “GUI,” can be used in thesingular or the plural to describe one or more graphical user interfacesand each of the displays of a particular graphical user interface.Therefore, a GUI can represent any graphical user interface, including,but not limited to, a web browser, a touch screen, or a command lineinterface (CLI) that processes information and efficiently presents theinformation results to the user. In general, a GUI can include aplurality of user interface (UI) elements, some or all associated with aweb browser, such as interactive fields, pull-down lists, and buttons.These and other UI elements can be related to or represent the functionsof the web browser.

Implementations of the subject matter described in this specificationcan be implemented in a computing system that includes a back endcomponent, for example, as a data server, or that includes a middlewarecomponent, for example, an application server. Moreover, the computingsystem can include a front-end component, for example, a client computerhaving one or both of a graphical user interface or a Web browserthrough which a user can interact with the computer. The components ofthe system can be interconnected by any form or medium of wireline orwireless digital data communication (or a combination of datacommunication) in a communication network. Examples of communicationnetworks include a local area network (LAN), a radio access network(RAN), a metropolitan area network (MAN), a wide area network (WAN),Worldwide Interoperability for Microwave Access (WIMAX), a wirelesslocal area network (WLAN) (for example, using 802.11 a/b/g/n or 802.20or a combination of protocols), all or a portion of the Internet, or anyother communication system or systems at one or more locations (or acombination of communication networks). The network can communicatewith, for example, Internet Protocol (IP) packets, frame relay frames,asynchronous transfer mode (ATM) cells, voice, video, data, or acombination of communication types between network addresses.

The computing system can include clients and servers. A client andserver can generally be remote from each other and can typicallyinteract through a communication network. The relationship of client andserver can arise by virtue of computer programs running on therespective computers and having a client-server relationship.

Cluster file systems can be any file system type accessible frommultiple servers for read and update. Locking or consistency trackingmay not be necessary since the locking of exchange file system can bedone at application layer. Furthermore, Unicode data files can bedifferent from non-Unicode data files.

While this specification contains many specific implementation details,these should not be construed as limitations on the scope of what may beclaimed, but rather as descriptions of features that may be specific toparticular implementations. Certain features that are described in thisspecification in the context of separate implementations can also beimplemented, in combination, in a single implementation. Conversely,various features that are described in the context of a singleimplementation can also be implemented in multiple implementations,separately, or in any suitable sub-combination. Moreover, althoughpreviously described features may be described as acting in certaincombinations and even initially claimed as such, one or more featuresfrom a claimed combination can, in some cases, be excised from thecombination, and the claimed combination may be directed to asub-combination or variation of a sub-combination.

Particular implementations of the subject matter have been described.Other implementations, alterations, and permutations of the describedimplementations are within the scope of the following claims as will beapparent to those skilled in the art. While operations are depicted inthe drawings or claims in a particular order, this should not beunderstood as requiring that such operations be performed in theparticular order shown or in sequential order, or that all illustratedoperations be performed (some operations may be considered optional), toachieve desirable results. In certain circumstances, multitasking orparallel processing (or a combination of multitasking and parallelprocessing) may be advantageous and performed as deemed appropriate.

Moreover, the separation or integration of various system modules andcomponents in the previously described implementations should not beunderstood as requiring such separation or integration in allimplementations, and it should be understood that the described programcomponents and systems can generally be integrated together in a singlesoftware product or packaged into multiple software products.

Accordingly, the previously described example implementations do notdefine or constrain the present disclosure. Other changes,substitutions, and alterations are also possible without departing fromthe spirit and scope of the present disclosure.

Furthermore, any claimed implementation is considered to be applicableto at least a computer-implemented method; a non-transitory,computer-readable medium storing computer-readable instructions toperform the computer-implemented method; and a computer systemcomprising a computer memory interoperably coupled with a hardwareprocessor configured to perform the computer-implemented method or theinstructions stored on the non-transitory, computer-readable medium.

A number of embodiments of these systems and methods have beendescribed. Nevertheless, it will be understood that variousmodifications may be made without departing from the spirit and scope ofthis disclosure.

What is claimed is:
 1. A computer-implemented method for validatingreservoir simulation models, comprising: (a) determining one or moretime segments of fluid recovery of a reservoir by analyzing a productionhistory of the reservoir; (b) generating, for a first time segment ofthe one or more distinctive time segments, one or more streamlines on afull simulation grid corresponding to the reservoir by performing one ormore reservoir simulations; (c) generating, for the first time segment,one or more drainage volumes by performing image analysis andcompression on the streamlines; (d) generating, for the first timesegment, a plurality of grid regions along one or more no-flowboundaries of the one or more drainage volumes; (e) generating, for thefirst time segment, a plurality of sector models corresponding to theplurality of grid regions by segmenting the full simulation grid alongthe one or more no-flow boundaries; (f) performing, for the first timesegment, a history matching process corresponding to a time phasesimultaneously on each of the plurality of sector models to generate,for each sector model of the plurality of sector models, a historymatching output; and (g) comparing, for the first time segment and foreach sector model of the plurality of sector models, the historymatching output for that sector model to a tolerance threshold.
 2. Themethod of claim 1, further comprising: (h) determining, for the firsttime segment and based on the comparing, whether the history matchingoutput for every sector model of the plurality of sector modelssatisfies the tolerance threshold; and (i) reconstructing, for the firsttime segment and in response to determining that the history matchingoutput for every sector model satisfies the tolerance threshold, thefull simulation grid by merging the plurality of sector models.
 3. Themethod of claim 2, further comprising: (j) determining whether thehistory matching process has been performed for all time segments of theone or more time segments; and (k) in response to determining that thehistory matching process has not been performed for all time segments ofthe one or more time segments, repeating steps (b)-(i) for a second timesegment of the one or more time segments.
 4. The method of claim 1,wherein the full simulation grid includes a three-dimensional simulationgrid.
 5. The method of claim 1, wherein performing image analysis andcompression includes performing a discrete cosine transform technique.6. The method of claim 1, wherein performing image analysis andcompression includes performing a pattern matching process to establishthe one or more no-flow boundaries of the one or more drainage volumes.7. The method of claim 1, wherein the plurality of sector modelsincludes at least one of: a matrix porosity model, a matrix permeabilitymodel, a fracture porosity model, a fracture permeability model, asaturation model, a rock type model, or a fluid region model.
 8. Asystem comprising: a computer-readable medium comprisingcomputer-executable instructions; and at least one processor configuredto execute the computer-executable instructions, wherein when the atleast one processor executes the computer-executable instructions the atleast one processor is configured to perform operations comprising: (a)determining one or more time segments of fluid recovery of a reservoirby analyzing a production history of the reservoir; (b) generating, fora first time segment of the one or more distinctive time segments, oneor more streamlines on a full simulation grid corresponding to thereservoir by performing one or more reservoir simulations; (c)generating, for the first time segment, one or more drainage volumes byperforming image analysis and compression on the streamlines; (d)generating, for the first time segment, a plurality of grid regionsalong one or more no-flow boundaries of the one or more drainagevolumes; (e) generating, for the first time segment, a plurality ofsector models corresponding to the plurality of grid regions bysegmenting the full simulation grid along the one or more no-flowboundaries; (f) performing, for the first time segment, a historymatching process corresponding to a time phase simultaneously on each ofthe plurality of sector models to generate, for each sector model of theplurality of sector models, a history matching output; and (g)comparing, for the first time segment and for each sector model of theplurality of sector models, the history matching output for that sectormodel to a tolerance threshold.
 9. The system of claim 8, the operationsfurther comprising: (h) determining, for the first time segment andbased on the comparing, whether the history matching output for everysector model of the plurality of sector models satisfies the tolerancethreshold; and (i) reconstructing, for the first time segment and inresponse to determining that the history matching output for everysector model satisfies the tolerance threshold, the full simulation gridby merging the plurality of sector models.
 10. The system of claim 9,the operations further comprising: (j) determining whether the historymatching process has been performed for all time segments of the one ormore time segments; and (k) in response to determining that the historymatching process has not been performed for all time segments of the oneor more time segments, repeating steps (b)-(i) for a second time segmentof the one or more time segments.
 11. The system of claim 8, wherein thefull simulation grid includes a three-dimensional simulation grid. 12.The system of claim 8, wherein performing image analysis and compressionincludes performing a discrete cosine transform technique.
 13. Thesystem of claim 8, wherein performing image analysis and compressionincludes performing a pattern matching process to establish the one ormore no-flow boundaries of the one or more drainage volumes.
 14. Thesystem of claim 8, wherein the plurality of sector models includes atleast one of: a matrix porosity model, a matrix permeability model, afracture porosity model, a fracture permeability model, a saturationmodel, a rock type model, or a fluid region model.
 15. A non-transitorycomputer storage medium encoded with computer program instructions thatwhen executed by one or more computers cause the one or more computersto perform operations comprising: (a) determining one or more timesegments of fluid recovery of a reservoir by analyzing a productionhistory of the reservoir; (b) generating, for a first time segment ofthe one or more distinctive time segments, one or more streamlines on afull simulation grid corresponding to the reservoir by performing one ormore reservoir simulations; (c) generating, for the first time segment,one or more drainage volumes by performing image analysis andcompression on the streamlines; (d) generating, for the first timesegment, a plurality of grid regions along one or more no-flowboundaries of the one or more drainage volumes; (e) generating, for thefirst time segment, a plurality of sector models corresponding to theplurality of grid regions by segmenting the full simulation grid alongthe one or more no-flow boundaries; (f) performing, for the first timesegment, a history matching process corresponding to a time phasesimultaneously on each of the plurality of sector models to generate,for each sector model of the plurality of sector models, a historymatching output; and (g) comparing, for the first time segment and foreach sector model of the plurality of sector models, the historymatching output for that sector model to a tolerance threshold.
 16. Thenon-transitory computer storage medium of claim 15, the operationsfurther comprising: (h) determining, for the first time segment andbased on the comparing, whether the history matching output for everysector model of the plurality of sector models satisfies the tolerancethreshold; and (i) reconstructing, for the first time segment and inresponse to determining that the history matching output for everysector model satisfies the tolerance threshold, the full simulation gridby merging the plurality of sector models.
 17. The non-transitorycomputer storage medium of claim 16, further comprising: (j) determiningwhether the history matching process has been performed for all timesegments of the one or more time segments; and (k) in response todetermining that the history matching process has not been performed forall time segments of the one or more time segments, repeating steps(b)-(i) for a second time segment of the one or more time segments. 18.The non-transitory computer storage medium of claim 15, wherein the fullsimulation grid includes a three-dimensional simulation grid.
 19. Thenon-transitory computer storage medium of claim 15, wherein performingimage analysis and compression includes performing a discrete cosinetransform technique.
 20. The non-transitory computer storage medium ofclaim 15, wherein performing image analysis and compression includesperforming a pattern matching process to establish the one or moreno-flow boundaries of the one or more drainage volumes.